What problem does this PR solve?

Issue Number: close #53504

Problem Summary:

Using .Value directly can easily cause wrong result and dangerous bug, especially for plan cache. We have found #53504 #53505 (and potentially many others). It's not possible to depend on test cases to avoid making mistakes in the future. Therefore, I propose to make .Value private.

What changed and how does it work?

However, it's not simple to make .Value private, because:

1. The Constant is always constructed directly, like Constant{Value:..., ...}. If we avoid using .Value directly, all these codes need to be changed.
2. The expression pkg is too big, and we also need to ensure the codes in expression pkg cannot access the .Value. However, golang allows the codes in the same package to access the private field.

Therefore, I wrote a linter to filter out all selector expression to get the .Value.

It's also hard to keep the correctness. I've considered the following three situations:

1. I just want to get the .Value field, and I'm sure it's not a parameter and deferred function.
2. I want to get the .Value field. If the current context is not in plan cache, evaluating parameter and deferred function is also fine.
3. I want to evaluate the parameter, deferred function, or simply return the value.

For most of the codes in optimizing stage, it should call 2. For the code in executing stage, it usually should call 3. We provide GetValue(), GetValueWithoutOverOptimization(), and .Eval for these three circumstances.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Fix the issue that in some situation, the result is different if the query is using plan cache.